Advances in computer network technologies continue to make sharing of information between systems increasingly efficient and affordable. Such advances have resulted in an increasing exploitation of networked systems, wherein new transmission infrastructures have emerged including wireless networks. As the quantity, speed, and complexity of networked systems have increased, corresponding network problems emerge. Typically, introduction of a dedicated, stand-alone, diagnostic device to the network commonly known as a network traffic analyzer can facilitate resolving network problems.
In general, a network traffic analyzer obtains key information about network traffic parameters and is capable of capturing and recording such data to provide a permanent record of communications on the network bus. Network traffic analyzers are capable of being controlled to begin and/or end recording based on the presence of certain conditions. Traditionally, a network traffic analyzer is a separate, dedicated piece of support equipment. Network traffic analyzers are generally PC based or are a specialized instrument and require specific network interface hardware and software modules to adapt to a particular network standard or configuration. Often the network should be analyzed and the diagnostic information collected while the network is being utilized by users in a live environment. Trouble-shooting network problems requires configuring a network traffic analyzer with an appropriate network interface module and associated software.
Moreover, in the industrial environment manufacturers typically require collection, analysis, and optimization of real time data from a plurality of sites that are located globally. One common solution for recording such data includes providing a local recording module(s) that often occupies a slot(s) in a control system's backplane, or which resides in another network. For example, a device(s) that acts as a historian(s) can communicate with controllers directly through the backplane, or can communicate remotely via a network interface. In addition, such historian can enable archiving data from the controller to an Archive Engine which provides additional storage capabilities.
In distributed control systems controller hardware configuration can be facilitated by separating the industrial controller into a number of control elements, each of which can perform a different function. Particular control modules needed for the control task can be connected together on a common backplane within a rack and/or through a network or other communications medium. Various control modules can also be spatially distributed along a common communication link in several locations. Such modular construction can further accommodate different applications that require various numbers and types of input/output (I/O) circuits, as can be determined by the particular device or process being controlled. Such stored control program runs in real-time to provide outputs to the controlled process (e.g., electrical signals to outputs such as actuators and the like.)
Data can be communicated with these remote modules over a common communication link, or network, wherein any or all modules on the network communicate via a common and/or an industrial communications protocol. Controllers within a control system can communicate with each other, with controllers residing in other control systems or with systems or applications outside of a control environment (e.g., business related systems and applications). Accordingly, management processes; such as diagnostic/prognostic measures for failure control, are becoming increasingly complex.
Moreover, in such environments, analysis and collaboration typically require interaction of two information streams, namely “internal” data (which is collected from an industrial unit(s), such as via historians, log collectors, and the like), and “external” data (which is associated with data traffic for network services.) In conventional systems, such two information streams are collected independently and analyzed separately—e.g., a first set of devices/analyzers collect internal data from the modules/units, and a second set of devices/analyzers gather data on network traffic. In general, available relation ships (e.g., timing relationships, sequence counting, and the like) between such two data streams are not readily apparent and are often deduced manually, hence adding to system inefficiencies. Moreover, in conventional systems, such two information streams are not synchronized together, and their collection does not depend on criticality of collection stage.